New Windows Shell API mapping: SHGetSpecialFolderPath #192
Conversation
WritePrivateProfileString of Kernel32.dll
|
As on Windows it is possible to map .ini files to be stored not on disk but in registry, using Java File API for accessing these is not sufficient. Hence we today added another commit providing GetPrivateProfileString, GetPrivateProfileInt and WritePrivateProfileString API mappings. Also, using these functions allow to get 100% the same syntax for parsing .ini files as native applications. We'd be glad if you would merge this into your code base. :-) |
| */ | ||
| public static final String getPrivateProfileString(final String appName, final String keyName, final String defaultValue, final String fileName) { | ||
| final char buffer[] = new char[1024]; | ||
| Kernel32.INSTANCE.GetPrivateProfileString(appName, keyName, defaultValue, buffer, new DWORD(buffer.length), fileName); |
There was a problem hiding this comment.
You should be checking error here and raising an exception.
There was a problem hiding this comment.
Actually, reading its description it looks like it cannot fail. Oh it comes from 16-bit times :)
There was a problem hiding this comment.
Actually this function will never fail but simply return the default! If the buffer is too small, the result is simply truncated. If the file is not found, the default is applied. Both are not necessarily failures but most likely are accepted by people used to this function. Typically, it is wanted behaviour that the default is returned if the file, the appname, or the key is missing -- instead of getting an exception. I think nobody ever checked for GetLatestError after this function, as the default's job is to get in place in case of any problem. Users would be scared if there is an exception thrown instead of getting the default. So if you insist for sake of OOP, I can throw an exception. But my advise would be in this particular function not to throw, for the sake of "expected behaviour". :-)
BTW, yes, this comes from 16 bit times, but in fact is still in use in lots of 32 bit software. ;-)
There was a problem hiding this comment.
You're correct. This is all good.
|
This is great. Can you please update CHANGES.md too? |
New Windows Shell API mapping: SHGetSpecialFolderPath
… subtype (java-native-access#192) Motivation: We should override the flush / read method so we return the correct sub-type for method chaining. Modifications: Add missing overrides and implementations Result: Be able to correctly method chain
Timothy and Daniel,
as discussed https://groups.google.com/forum/?fromgroups#!topic/jna-users/KUpYp8rzFwk before, here is the first of a few small extensions.
This one maps the Windows Shell API function "SHGetSpecialFolderPath" and provides a unit test for it. As we are porting some software 1:1 from C++ to Java, we needed to use this. I know that the same can be done with the already existing GetFolderPath, but we (and possible more) people like this (rather deprecated) function more, as it allows to be as simple as GetFolderPath(CSIDL), but has the option to create paths.
Would be great if you would accept this contribution.
More APIs are one the way. :-)